A Conceptual Model of Architecture Description
ISO/IEC/IEEE 42010 is based upon a conceptual model – or
“meta model” – of the terms and concepts
pertaining to Architecture Description. The conceptual model is
presented here using UML class diagrams to represent classes of
entities and their relationships.
The Core Ontology: ISO/IEC/IEEE 42010:2022 (second edition)
Here we provide a brief overview of changes and new concepts in
the 2nd edition of ISO/IEC/IEEE 42010. The new edition abandons a
UML-based meta model, but due to popular demand and to enable
comparison with the previous edition, a UML class diagram is used
here. Items in purple are new or changed from the previous edition.
Discussion of some of the changes follows the diagram.
The 2nd edition (2022) generalizes the subject of an architecture
description from System of Interest to Entity of
Interest. In the previous edition, an Architecture
View is comprised of one or more Architecture
Models. In the new edition, Architecture Model is
changed to View Component. This 2nd edition introduces
Stakeholder Perspectives as a means to group
Concerns and therefore to organize Viewpoints
framing those Concerns. This edition also introduces
Architecture Aspects: characteristics of the Entity
of Interest that are reflected in Architecture
Views. Among other uses, Aspects can be used to
refine the traceability between Concerns and
Views.
For historical perspective, the conceptual models in the first
edition (2011) are shown below.
For further comparison, its predecessor, the conceptual framework
used in the original IEEE 1471-2000™, can be found [here].
Context: ISO/IEC/IEEE 42010:2011 (first edition)
The first diagram captures terms and concepts of systems and
their architectures, as a context for understanding Architecture
Description.
Referring to the diagram:
Systems exist. A System is situated in its
Environment. That environment could include other
Systems.
Stakeholders have interests in a System; those
interests are called Concerns. A system’s Purpose
is one very common Concern. (Note: In the original edition of the
Standard, systems were said to have missions; in the
revision, Purpose was chosen as a more general
replacement to this term.)
Systems have Architectures. An Architecture
Description is used to express an Architecture of a
System.
- System
- The Standard takes no position on the question, What is a
system?
In the Standard, the term system is used as a placeholder
– e.g., it could refer to an enterprise, a system of
systems, a product line, a service, a subsystem, or software.
Systems can be man-made or natural. Nothing in the Standard
depends upon a particular definition of system. Users of the
Standard are free to employ whatever system theory they
choose.
The premise of the Standard is, For a system of interest to
you, the Standard provides guidance for documenting an
architecture for that system.
- Environment
- Every System inhabits its Environment. A System acts upon that
Environment and vice versa. A system’s Environment
determines the range of influences upon the system. In the
Standard, Environment is intended in the widest possible sense to
include developmental, operational, technical, political,
regulatory, and all other influences which can affect the
architecture. These influences are categorized as
Concerns.
- Architecture
- Systems have architectures. In the Standard, the
architecture of a system is defined as:
“fundamental concepts or properties of a system in its
environment embodied in its elements, relationships, and in the
principles of its design and evolution”.
The definition was chosen (1) to accommodate the broad range of
things listed above under System: the architecture
of X is what is fundamental to X (whether
X is an enterprise, system, system of systems, or some
other entity); and (2) to emphasize (via the phrase
“concepts or properties”) that a system can have an
architecture even if that architecture is not written
down.
For more about the definition, see
[Defining “architecture”].
- Architecture Description
- An Architecture Description (AD) is an artifact that expresses
an Architecture. Architects and other system stakeholders use
Architecture Descriptions to understand, analyze and compare
Architectures, and often as “blueprints” for planning and
construction. ADs are the primary subject of ISO/IEC/IEEE 42010
(and the focus of the next diagram).
The Core of Architecture Description: ISO/IEC/IEEE 42010:2011
(first edition)
The Standard is organized around the terms and concepts of the
diagram below. It depicts the contents of an AD and the relations
between those content items when applying the Standard to produce an
Architecture Description to express an
Architecture for some System of Interest.
- Architecture Description
- An Architecture Description is a work product used to express
the Architecture of some System Of Interest. The Standard
specifies requirements on ADs. An AD describes one possible
Architecture for a System Of Interest. An AD may take the form of
a document, a set of models, a model repository, or some other
form (AD format is not defined by the Standard).
See [Architecture Descriptions] for further
details and requirements on ADs.
- Stakeholder
- Stakeholders are individuals, groups or organizations holding
Concerns for the System of Interest. Examples of stakeholders:
client, owner, user, consumer, supplier, designer, maintainer,
auditor, CEO, certification authority, architect.
- Concern
- A Concern is any interest in the system. The term derives from
the phrase “separation of concerns” as originally
coined by Edsgar Dijkstra. Examples of concerns: (system) purpose,
functionality, structure, behavior, cost, supportability, safety,
interoperability.
- Architecture Viewpoint
- An Architecture Viewpoint is a set of conventions for
constructing, interpreting, using and analyzing one type of
Architecture View. A viewpoint includes Model Kinds, viewpoint
languages and notations, modeling methods and analytic techniques
to frame a specific set of Concerns.
Examples of viewpoints: operational, systems, technical, logical,
deployment, process, information.
- Architecture View
- An Architecture View in an AD expresses the Architecture of the
System of Interest from the perspective of one or more
Stakeholders to address specific Concerns, using the conventions
established by its viewpoint. An Architecture View consists of
one or more Architecture Models.
- Architecture Model
- A view is comprised of Architecture Models. Each model is
constructed in accordance with the conventions established by its
Model Kind, typically defined as part of its governing viewpoint.
Models provide a means for sharing details between views and for
the use of multiple notations within a view.
- Model Kind
- A Model Kind defines the conventions for one type of Architecture
Model.
AD Elements and Correspondences
Architecture Descriptions are comprised of AD Elements.
Correspondences capture relationships between AD Elements.
Correspondences and Correspondence Rules are used to express and
enforce architecture relations such as composition, refinement,
consistency, traceability, dependency, constraint and obligation
within or between ADs.
- AD Element
- Any item in an AD is considered an element. Every Stakeholder,
Concern, Viewpoint, View, Model Kind in an AD is an AD Element.
When a Viewpoint or Model Kind introduces constructs, these too
are considered AD Elements.
- Correspondence
- Correspondences express a relation between AD
Elements. Correspondences are used to express architecture
relations of interest within an Architecture Description or
between Architecture Descriptions. Correspondences can be
governed by Correspondence Rules.
- Correspondence Rule
- Correspondence Rules enforce relations within an Architecture
Description or between Architecture Descriptions.
Architecture Decisions and Rationale
Creating an Architecture involves making Architecture
Decisions. ISO/IEC/IEEE 42010 specifies requirements for capturing key
decisions within an AD in terms of the concepts shown in the next
diagram.
An Architecture Decision affects AD Elements
and pertains to one or more Concerns. By making a
Decision, new Concerns may be raised.
- Architecture Rationale
- Architecture Rationale records the explanation, justification or
reasoning about Architecture Decisions that have been made and
architectural alternatives not chosen.
Architecture Frameworks and Architecture Description Languages
Architecture frameworks and architecture description languages
(ADLs) are two mechanisms widely used in architecting. Instances of
each can be specified by building on the concepts of Architecture
Description presented above.
The diagram below depicts the contents of an Architecture Framework.
- Architecture Framework
- An architecture framework establishes a common practice for
creating, interpreting, analyzing and using architecture
descriptions within a particular domain of application or
stakeholder community. Examples of Architecture Frameworks: MODAF,
TOGAF, Kruchten’s 4+1 View Model, RM-ODP.
See [Architecture Frameworks] for
requirements and long list of examples.
- Architecture Description Language (ADL)
- An ADL is any form of expression for use in
Architecture Descriptions. An ADL might include a single Model
Kind, a single viewpoint or multiple viewpoints. Examples of ADLs:
Rapide, SysML, ArchiMate, ACME, xADL.
The diagram below depicts the contents of an ADL.
Resources for the ISO/IEC/IEEE 42010 website provided by
Olimpia.com.
Comments, corrections, suggestions on this site to:
Webmaster.